home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 383 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.8 KB
  1. Path: chaos.aoc.nrao.edu!usenet
  2. From: Chris Flatters <cflatter@nrao.edu>
  3. Newsgroups: comp.std.c
  4. Subject: Re: fflush: ANSI C v. POSIX.1
  5. Date: Thu, 15 Feb 1996 11:28:11 -0700
  6. Organization: NRAO
  7. Message-ID: <31237B3B.3238@nrao.edu>
  8. References: <4frf81$gmn@clark.edu>
  9. NNTP-Posting-Host: laphroaig.aoc.nrao.edu
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0b5 (X11; I; SunOS 5.4 sun4c)
  14.  
  15. James M. Cowen wrote:
  16. > 
  17. > Is the result of fflush(stdin) a fortuitous consequence of "undefined
  18. >                         ^^^^^
  19. > behavior" as described in ISO/ISE 9899 section 7.9.5.2 (p. 129) i.e.
  20. > it seems to act as if it does purge the streams buffer (ala fpurge()).
  21. > 
  22. > I've found the action to "work" on Solaris 2.X (and x86), hpux 9.X
  23. > 10.X, and Esix 5.4.1..
  24. > 
  25. > On Linux 1.1.59, the result of fflush(stdin) results in errno being set
  26. > to an error message number (either Illegal Seek or Unknown Error ...
  27. > depending on the sequence of inputs to the standard input.)
  28. > 
  29. > A disclaimer: I'm aware this group is not concerned with POSIX.1,
  30. > never-the-less, what about the following:
  31. > 
  32. > But, if I look over the POSIX.1 standard (ISO/ISE 9945), it seems to
  33. > imply under certain conditions, it's allowable to associate fflush()
  34. > with a stream open'd as read or update (pp. 159-161, 288-290 and 307), yet
  35. > in the Rational Section (p. 290, section B.8.2.3.4), POSIX.1 states:
  36. > 
  37. >      "There is no additional rationale provided for this subclause."
  38. > 
  39. > In short, I'm confused, can someone clarify how one would use fflush()
  40. > in a portable fashion ... no that's not what I want to ask.  Don't use
  41. > fflush() on a read/update stream,  that seems obvious given ANSI C, 
  42. > but it "works" on POSIX.1 systems, but POSIX.1 indicates it accepts 
  43. > the ANSI C standard, but ... I hope you get the drift of my question.
  44.  
  45. There is no conflict here.  ISO C does not impose any requirements
  46. on what an implementation of fflush() should do if it is called
  47. with an input stream as its argument.  An ISO C implementation
  48. can therefore do anything its designers think is reasonable.  On the
  49. other hand a program that calls fflush() on stdin is not a strictly
  50. conforming program (see ANSI/ISO 9899-1989 Section 4) since it relies
  51. on behaviour that is not defined by the standard.
  52.  
  53. POSIX.1 gives a specification for what fflush() should do if called
  54. on an input stream: specifically, that it should discard any pending
  55. data.  This is not in conflict with ISO C but places an additional
  56. restriction on an ISO C implementation.  Some of the behaviour that
  57. was left undefined by the ISO C standard becomes defined in an
  58. environment that conforms to POSIX.1.  A program that calls
  59. fflush() on stdin is therefore guaranteed to work in the same way
  60. (at least as far as that call is concerned) on any system that
  61. conforms to the POSIX.1 standard but not on all systems that
  62. conform to ISO C.
  63.  
  64. It is important to remember that portability is not an absolute
  65. quality but that there are different degrees of portability.
  66. A strictly conforming C program is guaranteed to run and to behave
  67. in the same way in any hosted ISO C environment.  A program that
  68. conforms to POSIX.1 is guaranteed to run and behave in the same way
  69. in that subset of ISO C environments that also conform to POSIX.1.
  70. This can be carried further: for example a program that conforms
  71. to the Single Unix Specification (the 1170 spec) is guaranteed
  72. to run and behave in the same way in that subset of POSIX.1
  73. environments that also conform to the Single Unix Spec.  There is
  74. an obvious trade-off to be made at each step: each step adds
  75. functionality or convenience but adds restrictions on portability.
  76. The cost of restricting portability has to be weighed against the
  77. loss of function or convenience that would be incurred by not
  78. accepting this restriction.
  79.  
  80. --
  81.  
  82. Chris Flatters
  83. cflatter@nrao.edu
  84.